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PREFACE 


This  volume  is  one  of  a series  vMch  documents  a Search  and 
Rescue  Simulation  Model  for  the  United  States  Coast  Guard.  The 
material  reported  in  this  documentation  was  developed  by  an  inter- 
disciplinary team  at  the  National  Bureau  of  Standards  with  representa- 
tion from  the  U.S.  Coast  Guard  under  MIPR  Z-70099-0-01935. 

The  complete  documentation  is  comprised  of  the  following: 

Volume  I Executive  Level  Documentation 

Volume  II  Analyst  Level  Documentation 

Volume  III  Programmer  Level  Documentation  for  "PREPROCESSOR" 

Volume  TV  Programmer  Level  Documentation  for  "OPSIM" 
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Appendix  A Flow  Charts  for  Programmer  Level  Documentation 
Appendix  B Program  Listings  for  Programmer  Level  Documentation 
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Executive  Level  Documentation 
ABSTRACT 

An  inter-disciplinary  team,  comprised  of  members  of  the  staff 
of  the  Technical  Analysis  Division  of  the  Bureau  of  Standards  and 
representatives  of  the  U.S.  Coast  Guard,  has  developed  a Search  and 
Rescue  Simulation  Model  (SARSIM) . Actual  or  projected  values  are 
used  for  such  parameters  as  location  of  Coast  Guard  stations;  types, 
deployments  and  capabilities  of  resources;  manning  levels;  case 
loads;  and  resource  assignment  policies.  Computer  runs  of  the  model 
can  then  provide  rapid  and  realistic  simulations  of  the  Search  and 
Rescue  (SAR)  process,  supplying  as  output  appraisals  of  the  degree 
to  which  satisfactory  service  is  provided,  utilization  of  individual 
resources  and  resource  types,  average  length  of  time  for  cases 
awaiting  service,  etc.  SARSIM  thus  represents  a powerful  managerial 
tool  with  which  Coast  Guard  planners  and  decision  makers  can  economically 
and  expeditiously  explore  the  likely  effects  of  proposed  major  changes 
in  allocation  or  mode  of  operation. 


iii 


INTRODUCTION 


The  United  States  Coast  Guard  has  been  tasked,  under  law,  to 
provide  Search  and  Rescue  (SAR)  services  to  people  and  property  in 
peril  on  the  high  seas  or  in  xvaters  subject  to  the  jurisdiction  of  the 
United  States.  Towards  fulfilling  this  mission,  approximately  $150 
million  is  budgeted  annually  for  12,000  Coast  Guardsmen  to  operate 
2734  vehicles  of  45  different  kinds  (i.e.,  boats  of  various  sizes, 
cutters,  fixed-wing  aircraft  and  helicopters)  at  285  stations  along  the 
Atlantic,  Pacific  and  Gulf  Coasts  of  the  continental  United  States, 
Alaska,  Hawaii  and  the  South  Pacific  and  such  inland  waterways  as  the 
Mississippi  River  and  the  Great  Lakes. 

The  management  of  such  a large  and  far-flung  enterprise  is 
clearly  a major  undertaking,  particularly  when  consideration  must 
continually  be  given  to  significant  changes  in: 

(a)  funding 

(b)  manning  levels 

(c)  operating  costs 

(d)  procurement  of  replacement  equipment  or  ordering  of  newly- 
developed  devices  or  vehicles 

or  (e)  demands  for  services,  which  may  go  up  with  increases  in 
recreational  boating  or  go  down  as  a result  of  succesful 
safety  programs. 

The  managerial  problems  referred  to  above  are  many  and  varied; 
the  approaches  proposed  to  solve  these  problems  may  be  even  more 
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numerous.  The  purpose  o£  this  paper  is  to  describe  an  analytical 
tool  designed  to  assist  Coast  Guard  decision  makers  in  their  explora- 
tions and  comparisons  o£  the  relative  e££ects  o£  various  changes  under 
consideration. 


CLASSES  OF  PROBLEMS  AND  DECISION  TOOLS 

Management  problems  concerned  with  SAR  are,  in  essence,  involved 
with  allocation  o£  limited  resources  with  the  goal  o£  achieving 
desired  levels  and  standard  o£  service.  Thus,  by  way  o£  examples, 
decisions  may  be  required  with  regard  to: 

(a)  establishment,  relocation  or  disestablishment  o£  shore 
stations  or  air  stations  within  a Coast  Guard  district; 

(b)  changes  in  manning  levels  at  individual  stations  or  through- 
out a district; 

(c)  relocation  o£  resources  £rom  one  station  to  another  or 
other  changes  in  the  relative  mix  or  availability  o£ 
di££erent  kinds  o£  resources; 

(d)  introduction  o£  new  types  o£  resources,  either  as  replace- 
ments £or  or  in  addition  to  existing  resources; 

or  (e)  decisions  whether  action  should  be  taken  in  anticipation  o£ 
radical  changes  in  demands  £or  services. 

Selection  o£  a course  o£  action  can,  o£  course,  be  made  in  the 
traditional  Fashion  o£  utilizing  individual  judgment  based  on  experience 
and  expert  opinion.  In  some  situations  it  may  be  possible  to  experiment 
with  changes  in  policy  or  equipment,  but  empirical  trials  in  actual 


-2- 


situations  are  often  time-consuming  and  costly,  and  often  entail  risk. 
Another  alternative  involves  modeling  and  analyzing  the  operation  and 
in  estimating  the  likely  outcome  of  the  proposed  courses  of  action.  In 
any  event,  the  results  of  experiment  or  of  analysis  are  presented  to 
the  aecision-maker  for  his  consideration  along  with  any  other  inputs. 

A tneoretical  model,  by  its  nature,  is  an  abstraction  from 
reality:  it  is  an  attempt  to  represent  a complex  process  in  sufficiently 

siiTiple,  idealized  fashion  that  it  can  be  manipulated  readily  and  with 
maximum  possible  flexibility.  At  the  same  time,  it  must  mirror  the 
real  v.orld  with  adequate  faithfulness  in  its  critical  elements  so  that 
results  from  the  model  will  be  accepted  as  applying  in  the  real  world. 
Such  models,  when  successfully  designed,  can  be  exercised  at  relatively 
low  cost  and  minimal  risk,  producing  objective  results,  generally  of 
a quantitative  nature. 

THE  SEARCH  AND  RESCUE  MODEL 

The  theoretical  model  of  the  search  and  rescue  mission,  which 
underlies  the  simulation  model  (SARSIM)  described  in  the  following 
section,  was  developed  by  an  interdisciplinary  team  of  analysts  and 
programmers  of  the  NBS  Technical  Analysis  Division  with  the  active 
cooperation  and  participation  of  representatives  of  the  Coast  Guard. 

As  a result,  it  is  considered  that  the  analytical  model  is  a reasonable 
and  valid  representation  of  the  search  and  rescue  process , including 
the  crucial  factors  which  affect  the  provision  of  services  required  at 
random  in  real  life.  The  model  takes  into  account  physical  locations 
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of  stations  and  resources;  capabilities  and  characteristics  of  resources 
policies  affecting  selection  of  resources  to  be  assigned  to  cases, 
manning  levels  for  shifts  and  vehicles,  and  acceptable  levels  of  service 
provided;  and  weather  and  sea  conditions.  In  addition,  the  nature  and 
rate  of  arrival  of  case  loads  are  based  on  historical  precedents,  but 
can  be  varied  at  the  discretion  of  the  user. 

Special  care  was  taken  during  development  of  the  model  to  insure 
that  characteristics  of  simulated  cases  and  services  were  realistic  and 
internally  consistent,  and  that  the  processes  simulated  reflected  the 
same  order  and  similar  detail  as  those  encountered  in  reality.  Some 
simplifications  were,  perforce,  required  for  the  sake  of  economy  and 
ease  of  operation,  but  artificialities  have  been  kept  to  a minimum. 

The  validity  of  the  model  has  been  tested  and  will  be  reported  on  in 
the  near  future.  However,  some  discussion  will  be  offered  in  the  latter 
part  of  this  volume  as  a prerequisite  to  establishing  credibility  and 
confidence  in  use  the  simulation. 

In  simplest  terms,  the  search  and  rescue  model  exemplifies  a 
typical  queueing  problem  wherein  customers  (i.e.,  cases  requiring 
Coast  Guard  services)  enter  the  system  at  random  times  to  be  serviced 
by  one  or  more  facilities  (that  is , here , Coast  Guard  resources) . A 
customer  being  serviced  ties  up  one  or  more  serving  facilities  for  an 
amount  of  time  dependent  on  the  location  of  the  case  and  the  type  and 
amount  of  service  required.  Accordingly,  new  customers  may  arrive  in 
the  system  and  have  to  wait  (in  a queue)  until  an  appropriate  facility 
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is  released  on  completing  its  last  service  or,  perhaps,  priorities  may 
require  breaking  off  service  in  progress,  putting  the  less  serious  case 
into  a queue.  On  the  one  hand,  the  desire  to  satisfy  ''customers"  might 
occasion  the  acquisition  of  enough  service  facilities  to  keep  queueing 
and  waiting  time  to  a minimum.  However,  it  might  be  considered  un- 
acceptable if  expensive  facilities  were  maintained  in  a standby,  but 
idle,  condition  to  achieve  the  aforementioned  objective.  Central  to 
this  problem,  moreover,  is  the  stochastic  nature* *  of  the  arrivals  and 
servicing,  hence  the  need  to  balance  requirements  for  long-term, 
steady-state  satisfaction  of  needs  with  the  possibility  of  temporary 
overloading  of  the  system  during  peak  periods  or  unusual  circumstances. 

It  might  be  noted  here  that  the  foregoing  remarks  apply  to  queueing 
problems  in  general,  and  are  not  elements  peculiar  to  the  SARSIM.  In 
fact,  one  of  the  uses  of  the  simulation  model  is  to  explore  reactions 
of  given  allocations  and  deployments  of  forces  to  marked  increase  in 
demand,  etc. 

AN  OVERVIEW'  OF  SARSIM 

The  Search  and  Rescue  Simulation  Model  (SARSIM)  is  an  event- 
oriented  computer  program  based  on  the  theoretical  search  and  rescue 
model  discussed  just  above.  The  simulation  is  keyed  to  specific  events , 
such  as  the  arrival  of  cases  requiring  service,  completion  of  service 
by  one  or  more  assigned  resources,  interruption  of  service  by  an 
assigned  resource  which  must  be  reassigned  to  a case  of  greater 

*A  stochastic  process  is  a highly  variable  sequency  of  events 
characterized  by  randomness  of  occurrence  at  each  point  in  time. 
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severity,  etc.  Consequently,  operation  of  the  program  proceeds  from 
one  significant  event  to  the  next,  with  an  internal  (simulated)  clock 
keeping  track  of  the  simulated  passage  of  time.  (To  illustrate  the 
nature  of  this  process  a sanple  simulation  of  a simple  SAR  situation 
is  presented  in  Appendix  A. ) 

The  computer  program  must  be  written  exactly  to  account  for  all 
possible  eventualities  within  the  simulation.  There  must  be  an 
appropriate  ordering  of  all  necessary  decisions  and  explicit  rules 
for  all  conceivable  alternatives.  The  simulation  then  effectively 
compresses  time  to  a high  degree,  completely  ignoring  the  passage  of 
time  during  which  nothing  significant  transpires. 

SARSIM  is  comprised  of  three  major  program  packages,  one  or 
more  of  which  may  be  employed  to  explore  a particular  set  of  conditions. 
The  first  major  component  in  the  sequence  is  the  PREPROCESSOR,  or 
PREPRO,  founded  on  a historical  accounting  of  cases  served  by  Coast 
Guard  stations.  As  described  in  general  terms  in  the  following 
section  (and  in  greater  detail  in  Volumes  II  and  III  of  this  series), 
PREPRO  is  used  to  generate  the  timing  of  case  arrivals  and  the  specifi- 
cation of  requirements  for  service.  In  other  words,  PREPRO  supplies  a 
scenario,  or  a preliminary  "event  list"  which  may,  if  desired,  be 
used  for  many  different  computer  runs. 

The  heart  of  SARSIM,  the  OPERATIONAL  SIMULATOR  (or  OPSIM) , is 
essentially  a bookkeeping  system  which  logs  in  arrivals,  registers 
their  needs,  investigates  the  availability  of  service  facilities,  assigns 
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resources  for  servicing,  and  generally  keeps  track  of  simulated  time 
spent  in  the  several  possible  activities  represented  within  the  model. 
OPSIM  is  described  in  somewhat  more  detail  below  and  is  fully  documented 
in  Volumes  II  and  IV  of  this  series. 

The  third  major  component  is  the  POSTPROCESSOR  (or  POSTPRO) . This 
program  module  permits  the  calculation  of  a variety  of  statistics  of 
interest  to  the  user,  either  as  a supplement  to  the  output  from  OPSIM 
(which  is  tailored  for  use  by  the  analyst)  or  to  enhance  the  usability 
and  comprehensibility  of  the  program’s  output.  POSTPRO  is  also  described 
in  a little  more  detail  below  and  in  fine  detail  in  Volumes  II  and  V 
of  this  series. 

A comparative  recapitulation  of  the  SAR  and  SARSIM  processes  may 
be  useful  as  a guide  for  following  the  descriptions  which  follow  in 
the  next  three  sections : 

(a)  Actual  cases  occur  at  random  times;  each  caise  has  a specifiable 
location  and  a particular  set  of  needs  for  service.  SARSIM  reproduces 
typical  cases  and  randomizes  their  injection  into  the  simulation  within 
the  PREPROCESSOR. 

(b)  When  the  Coast  Guard  receives  notice  of  a case  requiring 
service,  a suitable  resource  is  dispatched,  if  available.  SARSIM 
similarly  reviews  available  resources  for  suitability  in  assignment. 

Both  the  real  and  the  simulated  systems  keep  track  of  cases  waiting 
for  service  if  facilities  are  not  available.  The  OPSIM  portion  of 

the  model  makes  resource  assignments,  as  well  as  maintaining  statistics 
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o£  interest. 


(c)  The  Coast  Guard  periodically  assesses  SAR  performance,  in- 
cluding collation  of  data  on  individual  stations,  districts,  resource 
types,  and  classes  of  cases.  Similar  statistics  are  provided  as  the 
output  of  OPSIM.  In  addition,  POSTPRO  permits  specialized  sorting  and 
analysis  of  data  of  particular  interest. 

THE  PREPROCESSOR (PREPRO) 

The  Preprocessor, or  PREPRO,  serves  two  major  purposes  in  preparing 
for  runs  of  the  simulation  model.  The  first  of  these  is  data  extraction 
from  magnetic  tape  records  based  on  actual  cases  served  by  individual 
Coast  Guard  Stations.  PREPRO  derives  pertinent  parameters  from  these 
records  and  develops  a historical  case  file  for  an  entire  district. 

The  file  includes  information  on  the  types  of  emergencies , severity 
of  cases,  characteristics  of  personnel  or  property  involved,  weather 
and  sea  conditions,  number  and  kinds  of  services  rendered  for  search 
and/or  assistance,  etc.  The  historical  file  also  includes  a chrono- 
logical listing  of  the  past  occurrence  of  actual  cases  for  the  entire 
district  (i.e.,  the  cases  from  all  individual  stations  combined). 

At  the  option  of  the  user  of  the  simulation,  PREPRO  may  be  used 
to  generate  a scenario  based  on  the  historical  file  of  actual  cases, 
but  with  the  order  of  occurrence  determined  by  random  selection.  The 
user  also  has  the  option  of  selecting  the  case  load,  that  is,  the 
average  rate  of  arrival  of  cases  either  by  case  type,  or  by  station, 
or  by  district  as  a whole.  This  permits  examination  of  growth  in 
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demand,  level  demand,  or  possible  decrease.  The  user  also  specifies 
the  duration  of  the  period  to  be  simulated,  either  in  "calendar"  time 
or  by  number  of  cases  to  be  examined. 

The  output  of  tile  PREPRO  is  a magnetic  tape  listing  the 
historically  or  randomly  ordered  event  list,  plus  a tabulation  of  the 
statistics  of  the  scenario  generated.  It  may  be  observed  that  a 
randomly  ordered  list  of  events  may  be  re-used  for  as  many  runs  as 
one  chooses  with  variations  in  other  inputs. 

It  should  also  be  noted  that  the  scenarios  prepared  at  this  stage 
are  in  accord  with  the  statistics  of  the  past  and  are  internally  con- 
sistent. However,  if  desired  by  the  user  of  the  simulation,  attention 
can  be  paid  to  specific  kinds  of  variation  in  demand  for  services,  in- 
cluding general  or  specialized  growth.  For  example,  cases  may  be 
injected  to  reflect  new  types  of  service  demands  and  specialized  peak 
loads. 

OPSIM 

OPSIM,  the  central  portion  of  the  simulation  model,  accepts 
demand  schedules  for  service  from  the  PREPRO  output  and  determines  the 
number  of  needs  to  be  served,  assigns  resources,  and  measures  how  well 
services  are  supplied.  A set  of  input  parameters,  having  been  specified 
at  the  discretion  of  the  user*,  OPSIM  rapidly  calculates  how  the  SAR 
system  would  react  to  the  given  combination  of  demand  and  resources. 

* See  list  which  follows  immediately 
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For  example,  a summer's  case  load  for  an  entire  district  can  be 
simulated  in  about  10-15  minutes  running  time  on  the  conputer. 

The  critical  inputs  which  can  be  varied  by  the  user  to  capitalize 
on  the  wide-ranging  flexibility  of  the  model  include  the  following: 

(a)  Capabilities  and  characteristics  of  each  type  of  resource 
enployed,  including  endurance,  hourly  operating  cost,  relative  cost, 
speeds  achievable  in  various  operating  modes,  time  to  refuel,  relia- 
bility and  maintainability,  and  associated  delay  times. 

(b)  Locations  of  stations  in  district  and  listing  of  adjacent 
interactive  stations,  aircraft- covering  stations,  and  cutters;  numbers 
of  resources  of  each  type  assigned  to  each  station;  and  crew  manning 
levels  during  each  shift  at  each  station. 

(c)  Data  on  number  of  weekday  and  weekend  shifts  and  times 
shifts  end. 

(d)  Tolerance  times  for  each  severity  level,  that  is,  maximum 
acceptable  time  until  resource  arrives  to  provide  service  or  for 
searching,  depending  on  the  seriousness  of  the  case. 

(e)  Selectable  data  relating  to  searching  procedures,  especially 
with  regard  to  daylight  searching. 

(f)  Policy  selections,  especially  with  regard  to  use  of  resources, 
viz.,  when  station  receiving  call  for  service  uses  only  its  own 
resources,  or  whether  resources  from  adjacent  stations  may  be  utilized. 

Once  the  demand,  resource,  and  policy  inputs  have  been  prescribed, 
OPSIM  operates  on  the  cases  and  keeps  track  of  pertinent  statistics. 
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In  effect,  as  each  case  arrives  into  the  system  the  needs  associated 
with  it  are  examined,  including  the  possibility  that  search  will  have 
to  be  institutes,  or  that  two  or  more  resources  may  have  to  respond. 

If  appropriate  resources  are  available  to  service  a given  need^of  the 
case,  a particular  resource  facility  is  assigned  on  the  basis  of 
assignment  policies  and  either  (1)  greatest  operating  economy  achievable 
from  among  all  those  resources  which  can  satisfy  tolerance  time;  or 
(2)  the  resource  which  can  arrive  soonest  if  tolerance  time  cannot  be 
met. 

If  no  suitable  resources  are  idle  when  the  demand  for  service 
arises,  ongoing  service  to  a case  of  lower  priority  may  be  interrupted. 
If  no  suitable  resources  can  be  assigned,  the  case  is  placed  into  a 
queue  for  cases  of  the  same  severity  with  subsequent  periodic  review 
of  status.  When  resources  complete  services,  they  become  available 
for  reassignment  to  other  cases  or  to  return  to  station. 

At  each  change  in  status  (e.g. , cases  entering  or  leaving  queues, 
resources  assigned  to  or  conpleting  services,  etc.),  corresponding 
changes  are  made  to  running  counts  of  each  type  of  event  and  the 
simulated  time  spent  in  each. 

At  the  completion  of  the  operational  simulation  a file  may  be 
prepared  on  tape  of  the  various  case  attributes  for  subsequent  analysis 
within  the  Postprocessor.  In  addition,  OPSIM  also  generates  a printout 
including  the  follo\«.ng  types  of  data: 

(a)  District  statistics 


*Each  need  is  considered 
allocation  becomes  known. 


separately  as  the  requirement  for  resource 
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(1)  Number  of  cases  which  occurred;  number  of  cases  completed; 
the  number  of  failures  due  to  lack  of  suitable  resources  in  system 
or  at  primary  and  adjacent  stations;  and  the  number  of  failures  to 
satisfy  prescribed  tolerance  times. 

(2)  Average  utilization  statistics  overall,  by  shifts,  and 
by  resource  types;  of  boats,  cutters,  C-130’s,  and  other  aircraft. 

(3)  Number  of  standby  call-ups  and  unproductive  standby  call-ups. 

(b)  Station  Statistics 

(1)  Counts  of  cases  for  which  resources  from  given  station 
were  assigned  to  cases  or  were  first  to  arrive  on  scene;  failures 
of  the  types  listed  in  (a) (1) . 

(2)  Number  of  queues;  number  of  interrupted  services. 

(3)  Average  times  for  resources  to  transit  to  cases  and  for 
cases  awaiting  service;  average  waiting  times  when  tolerance 
exceeded  and  average  of  time  in  excess  of  tolerance. 

(4)  Miscellaneous  station  statistics,  including  calculation  of 
a figure  of  merit,  standby  call-ups,  unproductive  call-ups,  and 
utilization  figures. 

(c)  Statistics  on  groups  within  district,  similar  to  those  for 
stations. 

(d)  Resource  statistics,  including  number  of  times  assigned  and 
average  utilization  indices. 

(e)  Printout  of  attributes  of  exceptional  cases,  such  as  any  needs 
which  cannot  be  met  with  any  available  resources. 


-12- 


(f)  Utilization  statistics  and  average  times,  as  under  station 
statistics,  segregated  by  weekday  and  weekend. 

(g)  Lists  of  cases  remaining  in  queue  and  all  busy  resources  at 
the  end  of  the  simulation. 

THE  POSTPROCESSOR  (POSTPRO) 

The  foregoing  list  of  the  OPSIM  outputs  illustrates  how  the 
data  presented,  although  fairly  detailed,  are  to  a considerable  extent 
aggregated  over  what  might  easily  be  a large  number  of  quite  varied 
cases.  The  function  of  POSTPRO  is  to  enable  the  user  to  acquire 
statistics  of  interest  for  a more  highly  selected  group  of  cases.  To 
this  end,  the  details  of  individual  cases  may  be  accumulated  on  tape 
by  OPSIM  for  manipulation  within  POSTPRO. 

POSTPRO  has  what  is  termed  "QUICK  QUERY,"  a computer  routine 
which  enables  the  user  to  specify  classes  of  cases  of  special  interest 
(such  as  cases  occurring  in  a particular  geographic  area  or  at  a 
given  minimum  distance  from  shore  and  also  requiring  tow,  etc.),  as 
well  as  formulas  for  desired  calculations  and  the  sequence  in  which 
the  output  is  to  be  produced. 

CREDIBILITY  OF  THE  SIMULATION  MODEL 

As  stated  earlier,  considerable  effort  was  devoted  to  establishing 
realism  in  the  analytical  model  by  invoking  the  aid  of  operationally  - 
experienced  Coast  Guardsmen  and  attempting,  to  the  maximum  extent  possible, 
to  pattern  the  model  after  actual  Search  and  Rescue  practices.  This 
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meant  careful  attention  to  the  choice  of  significant  events  and  to 
the  sequence  and  manner  of  effecting  assignments  within  the  system. 

In  addition,  certain  internal  parameters  had  to  be  assigned  numeri- 
cal values : these  were  set  and  varied  in  a series  of  calibration  runs 
for  each  district  investigated.  Using  the  historical  data  files,  cases 
can  be  (and  were)  presented  to  the  simulation  exactly  as  they  occurred 
in  time  and  space.  Comparison  of  the  statistics  produced  by  OPSIM  after 
simulated  SAR  were  made  with  similar  statistics  for  the  actual  events. 
There  was  good  agreement  between  the  two  sets  of  data  ,to  be  documented 
in  a forthcoming  report  on  the  analysis  of  validation  tests. 

Another  set  of  tests,  which  are  also  to  be  reported  on  in  the 
cited  upcoming  report,  demonstrated  that  outputs  changed  in  the 
expected  direction  when  slight  changes  were  made  to  selected  input 
parameters . 

GENERAL  EXAMPLES  OF  THE  USE  OF  SARSIM 

As  should  now  be  clear,  SARSIM  is  a tool  with  which  a manager 
may  explore  the  likely  effects  of  conceivable  changes  to  the  SAR 
system.  It  not  only  supplies  data  on  expected  performance  for  one 
particular  set  of  inputs , but  may  also  be  used  to  ascertain  the  effect 
of  selective  variations,  including  changes  made  on  the  basis  of  results 
derived  in  a preceding  set  of  runs.  The  use  of  the  simulation  model 
provides  a widely- expanded  base  of  information  which  the  decision-maker 
may  consider,  along  vrith  subjective  judgments,  prior  to  choosing  a 
course  of  action. 
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It  is  also  noteworthy  that  the  executive  need  not  know  the 
inner  workings  o£  the  program  in  any  great  detail,  nor  need  he  know 
the  language  of  the  computer.  An  analyst,  serving  as  intermediary, 
converts  the  user’s  desires  and  the  pertinent  background  information 
into  the  machine  parameters  necessary  to  activate  the  simulation.  The 
analyst  should  also  be  responsible  for  translating  and  presenting  the 
output  data  from  OPSIM  and  POSTPRO.  The  executive  may  then  exercise 
his  option  of  accepting  or  rejecting  --  or  of  revising  his  initial 
questions  and  occasioning  some  additional  computer  runs. 

The  kinds  of  simulation  runs  which  might  arise  are  illustrated 
in  two  following  examples. 

(1)  If  two  stations  within  a given  district  are  to  be  closed 
(as  was  actually  scheduled  to  occur) , what  effect  would  this  be  expected 
to  have  on  the  provision  of  SAR  services? 

It  might  be  anticipated  that  the  loads  previously  handled  by  these 
stations  would  be  taken  up  by  their  immediately  adjacent  neighbors  in 
roughly  equal  shares.  However,  it  might  not  be  obvious  in  advance 
whether,  with  the  two  stations  closed,  service  to  clients  would  suffer. 
The  simulation  showed  that  over  80%  of  the  cases  previously  handled  by 
the  two  closed  stations  were  indeed  picked  up  by  the  nearby  shore 
stations,  but  in  unexpectedly  unequal  fractions:  the  disparity  seems 

to  be  due  to  the  geographical  locations  of  the  particular  stations 
involved  and  the  sites  of  case  occurrence  relative  to  these  stations 
of  interest.  (The  other  cases  not  reassigned  to  nearby  shore  stations 
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were  handled  by  cutters  or  aircraft.) 

With  the  two  stations  closed,  there  were  no  increases  in  the 
number  of  failures  to  meet  prescribed  tolerance  times  (i.e.,  maximum 
allowable  waiting  times)  at  the  shore  stations  which  took  up  the  slack, 
but  there  was  an  additional  failure  of  this  type  occurring  at  one  of 
the  covering  aircraft  stations.  It  is  also  interesting  to  note  that 
waiting  times  for  clients  served  by  the  adjacent  shore  stations  were 
essentially  unchanged  (in  fact,  they  went  down  by  about  1 minute).  At 
the  same  time,  the  average  waiting  times  for  clients  served  by  the 
stations  picking  up  the  extra  load  went  up  about  10  minutes.  In  other 
words,  the  simulation  revealed  that  the  two  stations  to  be  closed  were 
serving  distant  cases , causing  extensive  waits.  Closing  these  stations 
would  then  be  expected  to  increase  utilization  at  nearby  stations,  but 
without  causing  undue  waits  for  the  clients. 

(2)  If  a new  resource,  such  as  an  air  cushion  vehicle  (ACV) 
becomes  available,  to  what  extent  and  benefit  would  it  supplement  or 
replace  existing  resources? 

This  problem  might  be  explored  by  selecting  a district  and 
specifying  various  mixes  of  old  and  new  resources.  The  simulation 
might  be  run  to  represent  a future  summer  with  considerable  growth  in 
case  loads.  Given  the  performance  capabilities  of  the  ACV,  a scenario 
would  be  generated  in  PREPRO,  then  run  through  OPSIM  for  each  of  the 
sets  of  input  values,  corresponding  to  the  prescribed  resource  mixes. 

The  results  of  such  a simulation  could  be  compared  with  one 
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another  to  indicate  the  relative  costs  of  those  mixes  which  afforded 
the  same  levels  of  SAR  services  or,  if  costs  were  fixed,  the  mixes 
offering  minimum  waiting  times  for  the  most  severe  (or  for  all)  cases, 
etc. 

Reviewing  the  preceding  examples,  it  should  be  clear  that  the 
simulation  model,  in  essence,  interprets  the  effects  of  choosing  a 
particular  set  of  input  conditions  which  describe  the  resources  available 
and  the  service  demands  to  be  exerted  on  the  system.  Granting  that 
the  model  is,  indeed,  an  adequate  representation  of  the  real  world 
search  and  rescue  system,  SARSIM's  predictive  ability  is  strictly 
limited  to  man's  ability  to  forecast  the  input  elements,  including  un- 
invented resources  and  future  waterborne  crises.  Tn  this  regard, 
however,  the  simulation  can  be  of  great  assistance  by  permitting 
examination  of  unusual  peak  demands  for  service. 

As  suggested  by  the  first  of  the  examples  cited,  the  simulation 
may  well  produce  somewhat  unexpected  results.  Such  surprises  must  be 
carefully  examined  for  clues  as  to  cause,  for  they  frequently  provide 
insights  into  situations  \\hose  intricacies  are  not  readily  apparent. 

CONCLUDING  REMARkS 

The  intent  of  this  volume  has  been  to  offer  the  executive  a broad 
overview  of  the  nature  of  the  Search  and  Rescue  Simulation  Model  (SARSIM) . 
The  level  of  detail  presented  has  been  restricted  to  that  necessary  for 
a general  understanding  of  the  processes  involved,  as  well  as  the  benefits 
and  limitations  associated  with  its  use.  The  relationship  of  the  model 
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to  SAR  problems  has  been  illustrated  in  the  text,  and  a micro-scale 
simulation  is  exemplified  in  Appendix  A.  The  reader  who  is  interested 
in  exploring  SARSIM  in  finer  detail  is  referred  to  Volume  II  of  this 
series,  which  provides  Analyst  Level  Documentation.  (The  remaining 
volumes  are  dedicated  to  Programmer  Level  Documentation,  and  are 
intended  for  use  by  those  directly  concerned  with  machine  runs.) 

Finally,  the  accompanying  table  is  a guide  to  the  approximate 
costs  for  making  different  kinds  of  computer  runs  with  SARSIM.  Ranges 
of  values  are  shown  in  some  instances  since  there  are  uncertainties 
with  regard  to  the  degree  of  complexity  likely  to  be  encountered.  In 
particular,  it  should  be  observed  that  PREPRO  runs  which  simulate  a 
month’s  load  or  less  can  provide  a menu  of  ten  scenarios;  only  a 
single  scenario  is  produced  for  the  costs  shown  for  longer  periods. 
However,  as  stated  earlier,  a single  scenario  may  be  re-used  over  and 
over  within  a district  for  many  sets  of  resource  inputs.  The  costs 
shown  for  POSTPRO  are  subject  to  considerable  variation,  depending 
on  the  complexity  of  queries.  It  should  be  recalled  that  POSTPRO  is 
used  selectively  when  particularized  manipulation  of  OPSIM  output  data 
is  desired. 
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APPROXIMATE  COSTS  FOR  SARSIM  RUNS* (in  dollars) 


le  Simulated 

No.  of  Cases 

PREPRO  COSTS 

OPSIM  COSTS  POSTPRO  COSTS 

1 Day 

30 

20# 

10 

15-30 

1 Month 

1000 

30# 

20-40 

40-100 

3 Months 

3000 

35## 

40-80 

150-350 

1 Year 

10000 

75## 

125-250 

300-850  or  more 

* For  one  district 
#10  scenarios  provided 
##  1 scenario  provided 
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APPENDIX  A 


A SAMPLE  SIMULATION  OF  A SIMPLE  SAP  SITUATION 

The  example  which  follows  has  been  designed  to  illustrate 
how  a SAR  siutation  might  be  simulated.  Although  the  methodology 
followed  is  completely  analogous,  the  SARSIM  model  is,  of  course, 
far  more  complex  in  terms  of  numbers  of  stations,  resources,  decision 
rules,  and  so  fortli.  Nonetheless,  the  material  in  tliis  appendix 
may  be  useful  for  sup]')lying  an  appreciation  of  the  concept  operation, 
and  use  of  a simulation  modei . 

The  types  of  cases  requiring  SAR  services  will  be  classified  here 
as  being  either  serious  or  non-serious.  It  is  assumed  on  the  basis 
of  past  records  that  the  distribution  of  severity  of  cases  will 
continue  to  be  in  the  ratio  of  5 -to-  1,  non-serious  over  serious. 

It  is  furthermore  anticipated  that  half  of  the  cases  will  continue 
to  involve  equipment  failures,  one- third  will  require  evacuation 
from  positions  of  peril,  and  the  remaining  one-sixth  will  necessitate 
search. 

The  resources  to  be  examined  in  this  situation,  specified  by  the 
user  of  the  simulation,  are  a helicopter  and  a utility  boat,  to 
be  assigned  to  cases  in  accordance  with  the  policy  rules  established 
in  Table  A-1.  The  figures  in  parentheses  indicate  the  probabilities  of 
occurrence  stipulated  above.  It  may  be  noted,  as  shown  in  the  table, 
that  all  probabilities  have  been  selected  as  multiples  of  sixths , 


A-1 


hence,  if  desired,  the  simulation  may  be  played  manually*  by  rolling 
dice,  specifying  in  advance  the  association  between  each  possible  die 
position  and  the  event  to  be  associated  with  it. 

Table  A-1 


Resource  Assignments  for  Sinple  SAR  Simulation 
(Figures  in  parentheses  indicate  probability 
of  occurrence  of  indicated  event) 


Red  Die 
Face 

Nature  of  Distress 

Severity  of  Case 

Non- Serious 
(5/6) 

Serious 

(1/6) 

1,2,3  (1/2) 

Equipment  Failure  (1/2) 

Boat 

Both 

4,5  (1/3) 

Evacuation  (1/3) 

Boat 

Helo 

6 (1/6) 

Search  (1/6) 

Helo 

Both 

Green  Die  Face 

1,2, 3, 4, 5 (5/6) 

6 (1/6) 

The  SAR  situation  which  is  being  simulated  consists  of 
a series  of  cases  which  randomly  arrive  into  the  system;  which 
are  placed  in  queues  (waiting  lines)  if  service  facilities  are 
not  immediately  available  or  which  are  serviced  if  the  necessary 
facilities  are  available;  which  require  variable  amounts  of 

*This  w^  done  experimentally  to  produce  the  results  furnished  below. 
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service,  hence  time  for  servicing;  and  which  leave  the  system 
when  services  have  been  completed.  The  essential  nature  of  the 
simulation  is  that  it  is  keyed  to  events  (such  as  arrivals,  servicing, 
and  departures);  an  internal  (simulated)  clock  keeps  track  of  time, 
completely  ignoring  the  passage  of  time  during  which  nothing  significant 
transpires.  Effectively,  time  is  drastically  compressed,  provided  that 
decision  rules  have  been  established  within  the  program  to  account  for  all 
possible  events,  with  an  appropriate  ordering  of  simulated  actions. 

For  this  simulation,  it  remains  to  assign  mechanisms  for  determining 
arrival  and  service  times.  For  illustrative  purposes  only,  it  is  assumed 
that  lapses  of  (precisely)  40,  80  or  120  minutes  between  successive 
arrivals  to  the  system  are  equally  likely.  A roll  of  a red  die  might 
then  be  used  to  determine  the  onset  of  each  new  case,  with  faces  1 or  2 
indicating  a lapse  of  40  minutes  since  the  last  case  arrived;  faces 
3 and  4 for  an  80 -minute  lapse;  and  faces  5 and  6 for  a 120 -minute  lapse. 
Similarly,  the  following  mechanism  was  chosen  to  determine  service  time 
for  cases; 


Green  Die  Face 


Probability 


Service  Time  (min) 


1 


1/6 


30 


2,  3,  4 


1/2 


60 


5 


1/6 


90 


6 


1/6 


180 
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Even  for  this  simple  SAR  system,  the  number  of  events  and 
alternatives  is  fairly  large  and  must  be  carefully  and  exactly 
accounted  for,  as  illustrated  schematically  in  the  flav  chart  of  figure 
A-1.  The  sequence  may  be  described,  with  commentary,  as  follows: 

1.  Initialize  the  system  and  go  to  Step  2.  All  variables  including 
clock  time  and  numbers  of  cases  in  queue  or  in  processing,  are  set  at 
zero;  first  case  will  arrive  at  time  zero. 

2.  Determine  the  time  for  the  next  arrival  to  the  system;  place  the 
item  on  an  event  list;  go  to  Step  3. 

In  this  example,  the  red  die  would  be  rolled  to  determine  whether 
the  next  case  would  follow  its  predecessor  by  40,  80,  or  120  minutes. 

3.  Determine  the  nature  of  the  distress  and  the  case  severity  to 
determine  the  required  resource (s);  go  to  Step  4. 

Both  dice  would  be  rolled  to  determine  whether  the  boat,  helicopter, 
or  both  would  be  required,  as  shown  in  Table  A-1. 

4.  Assign  available  resources  to  case;  go  to  Step  5.  If  resources 
are  busy,  place  case  in  appropriate  queue;  go  to  Step  6. 

Separate  queues  are  maintained  for  serious  and  non- serious  cases 
awaiting  service  while  resources  are  tied  up.  As  resources  become 
available,  queues  are  examined,  as  indicated  in  Step  7. 

5.  Generate  a service  time  for  assigned  resources;  compute  time 
of  completion  of  service;  place  event  on  the  event  list  in  its  proper 
chronological  order;  go  to  Step  6. 
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The  green  die  is  rolled  to  select  service  time,  as  described  above. 
Case  arrivals  and  service  completions  are  both  placed  on  the  event  list 
in  their  chronological  order  of  occurrence.  The  random  arrivals  may 
therefore  occur  while  facilities  are  tied  up  or  after  they  have  been 
freed. 

6.  Determine  the  type  of  event  nexr  on  the  event  list:  if  it  is 

an  arrival,  advance  the  simulated  clock  and  go  to  Step  2;  if  it  is  a 
completion,  advance  the  clock  and  go  to  Step  7. 

7.  Compute  the  busy  time  for  the  resource  which  has  just  completed 
service;  search  the  queue  for  serious  cases  to  determine  whether  this 
resource  can  be  utilized;  if  so,  calculate  the  waiting  time  in  queue 

for  the  case  to  be  serviced  now,  remove  that  case  from  the  queue, 
and  go  to  Step  5.  If  there  are  no  serious  cases  awaiting  the  newly-freed 
resource,  examine  the  non-serious  queue  to  determine  if  the  resource  can 
be  used;  if  so,  proceed  as  with  serious  case.  If  the  resource  is  not 
needed  by  any  cases  in  queue,  go  to  Step  6. 

The  process  is  continued,  as  outlined  above,  until  some  specific 
number  of  cases  have  been  run  or  some  other  indicator  of  the  end  of 
simulation  occurs.  In  retrospect,  it  will  be  seen  that  a random  set  of 
arrivals  has  been  generated,  each  occasioning  an  assignment  of  the  boat 
or  helicopter  or  both  for  a random  choice  of  servicing  time.  During 
the  course  of  the  simulation,  queues  may  have  been  established 
for  either  or  both  of  serious  and  non-serious  cases  awaiting  assignment 
of  a busy  resource.  The  bookkeeping  features  of  the  process  have  accounted 
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for  numbers  of  cases  in  queues,  time  spent  waiting,  times  spent 
in  servicing  cases,  and  total  elapsed  time  within  the  simulation. 

It  becomes  possible,  then,  to  prepare  summary  statistics  of  the  type 
shown  in  Table  A-2,  derived  from  a manual  simulation  of  100  cases 
in  accordance  with  the  simulation  rules  described  in  this  appendix. 

The  table  also  shows  results  of  a second  simulation,  run  in  the  same 
general  fashion,  but  using  two  boats  and  one  helicopter  as  available 
resources.  The  additional  boat  was  intended  as  a means  to  reduce  the 
average  waiting  time  for  the  non-serious  cases;  the  differences  between  the 
two  sets  of  figures  derive  largely  from  the  availability  of  the  second  boat, 
but  are  also  strongly  affected  by  the  vagaries  of  chance.  Thus,  for 
example,  the  apparent  increase  in  average  waiting  time  for  serious  cases 
is  solely  attributable  to  the  fact  that,  in  the  second  running  of  the 
simulation,  the  single  serious  case  which  had  to  wait  for  a resource 
arrived  while  another  serious  case  was  being  processed. 

It  must  be  emphasized  that  the  sample  simulation  shown  in  this 
appendix  is  a pure  invention  for  illustrative  purposes  only.  It  is  highly 
artificial,  not  merely  with  regard  to  its  simplistic  nature,  but  also  by 
virtue  of  the  fact  that  the  sets  of  resources,  arrival  and  service  rates, 
and  assignment  rules  bear  small  resemblance  to  actuality.  Despite  its 
simplicity,  it  should  be  obvious  that  this  simulation  process  is  complicated 
and  time  consuming;  the  more  con^lex  SARSIM  clearly  requires  computerization. 
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Table  A- 2 


Summary  Results  of  Two  Sample  Simulation  Runs 


Number  of  boats  available 
Number  of  helicopters  available 
Number  of  cases  in  run 
Number  of  serious  cases 
Number  of  serious  cases  to  queue 
Probability  of  serious  case  queueing 
Average  waiting  time,  serious  cases 
Number  non- serious  cases  to  queue 
Probability  of  non-serious  case  q’ing 
Average  waiting  time,  non-serious  cases 
Helicopter  time  available* 

Helicopter  time  busy 
Boat  time  available* 

Boat  time  busy 


First  Sample 

Second  Sample 

1 

2 

1 

1 

100 

100 

17 

17 

4 

1 

4/17=. 24 

1/17=. 06 

15  min 

20  min** 

45 

13 

45/83=. 54 

13/83=. 16 

111  min 

85 

8070  min 

8070  min 

3330  min 

3270 

8070  min 

16140  min 

5940  min 

6210  min 

* In  this  context  based  on  duration  of  simulated  run.  This  takes  no 
account  of  manning  considerations , etc. 

**  Based  on  single  case  in  queue;  see  text. 
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